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The information contained in this document relates to Prestel Public Service 
version 46. 


NOVEMBER 1981 


SECTION 1 INTRODUCTION 


The Prestel System offers two independent methods by which an Information Provider 
(IP) may update the database. The ‘online editor’ is used by an IP keying 
information directly into the system from a standard viewdata terminal and 
editing keyboard. ‘Bulk Update’ is used where the input data is supplied 

to Prestel by another computer system, or by a microprocessor-based intelligent 
editing terminal. 


Although the two input methods are independent, a substantial part of the 
processing performed by the Prestel system is the same for both types. In 
particular, input data for both systems is subject to the same security and 
integrity checks. 


This document describes the formats and protocols require for Bulk Update. 
A working knowledge of the Prestel system and the online editor is assumed. 


At present, two different input media are available to Bulk Updaters: 

Magnetic tape batch update, with reports output to a line printer; 

On-line update via a telephone line, using an asynchronous protocol. 
It is planned in the future to introduce in addition a synchronous on-line 
protocol. This will use the IBM 'BSC' protocol, as defined in the IBM reference 
manual 'General Information - Binary Synchronous Communications! GA27-3004-2. 


The GEC implementation of the protocol which will be used by the Prestel system 
is described in the GEC manual 'Synchronous Communications! DD1306. 


SECTION 2 RECORD TYPES 


1 This section describes the record types available to the Bulk Update 
user. Detailed input record layouts are at Appendix B, with explanatory notes 
at Appendix A. A copy of the viewdata character code table is at App F. 


2 It should be noted that the records are processed serially - the database 
is updated by each record in turn. The IP must ensure that the records appear 
in a valid order; for example, a page may not be deleted while any filials 
exist. 


RECORD TYPES 


3 RUN HEADER/LOGON RECORD The first record of a run (magtape or online) must 
by a ‘logon request’, to identify the IP to Prestel and enable his file data 
(logo, CUGs etc) to be accessed. The record contains the following information:- 


3.1 USER ACCESS CHECKS The record contains a systelno and an editing 
password identical to the current password used by the IP for online 
editing. If the run header is not the first record, or if the systelno 
or editor password are invalid, an appropriate error message is output 
(see App C) and the bulk update run is stopped. 


3.2 OUTPUT IDENTIFICATION (MAGTAPE ONLY) The record also contains a 
name and address which are printed on the first page of the output report. 


3.3 ONLINE UPDATE. If the 'reply wanted' indicator was set on the 
input record, a full ‘logon reply' is transmitted to the IP's computer 
(format at App C page 1), otherwise a standard 'update ok' (ie a '0') 
is transmitted. | 


4 BATCH HEADER (MAGTAPE ONLY) This signals the start of a batch of update 
records. 


5 BATCH TRAILER (MAGTAPE ONLY) This signals the end of a batch of update 
records, and contains counts of the number of records in the batch. 


6 UPDATE RECORDS These records are used to update the framefile on the 
database. The six data types available are: 


6.1 INSERT FRAME This record is used to enter a page or frame (equivalent 
to the ‘enter’ option in the online editor) and therefore contains the 
appropriate fields ie page number, frame-id, cugs, frame type, price, 
routeing choices and frame contents. 


6.2 REPLACE FRAME TABLE THis record is used to amend an existing frame 
(equivalent to the 'overwrite' option ín the online editor) and contains 
the same fields as 'insert frame' (para 6.1). 


NOTE: The frame contents field may be omitted in this record, thus amending 
only the frame coutrol information, and leaving the displayed information 
unaltered. 


6.3 REPLACE FRAME This record is used to amend only the displayed part 
of an existing frame (equivalent to the 'amend' option in the online 
editor). It contains an identifying page number, frame identity and 

the frame contents field. Note that the frame contents are completely 
replaced by the new version - there is no facility to supply amendment 
data only. 


6.4 DELETE PAGE This record is used to delete all the frames of a page 
(equivalent to 'delete раве! option in the online editor). It contains 
just an identifying page number. 


6.5 DELETE FRAME This record is used to delete the last frame of a page, 
ie frame identity b-z (equivalent to 'delete frame' option in the online 
editor). It contains an identifying page number and frame identity. 


6.6 REINSERT FRAME This record type, for which there is no equivalent 
in the online editor, acts as a 'replace frametable' (see 6.2) if the 
frame already exists оп the database, ог as an 'insert frame! (see 6.1) 
if it does not exist. 


7 RETRIEVE FRAME This record contains a page number and a frame identity, 
and results in à frame being retrieved from the database. Only the IP's own 
frames may be retrieved in this way. 


7.1 MAGTAPE UPDATE The frame and its control details are printed on 

the output report. Control characters are not printed and graphics characters 
are replaced by '*'. Only 30 such records are allowed in a batch, any 

extra ones being ignored. 


7.2 ONLINE UPDATE The frame and its control information are transmitted 
to the IP's computer in the format shown at App C page 3. 


8 MESSAGE CONTROL RECORDS (ONLINE ONLY) 


These record types are used to retrieve message/response frames or send messages 
to other IP's, equivalent to the facilities available on pages 930 and 931 in 
the online user system. 4 record types are available: 


8.1 RETRIEVE NEW MESSAGE. This results in the transmission of the first 
new message to the IP's. computer, (layout at Appendix C). If no new 
messages are available, an error code is sent (Appendix D4). Note that if 
the next record is neither a STORE MESSAGE nor a DELETE MESSAGE, this message 
remains the first new message, so another RETRIEVE NEW MESSAGE will get 

the same message again. 


As for the online user system, a charge is made for message retrieval. 
At present, the IP's frame charge total is incremented by 3p for each 
new message retrieved. 


8.2 RETRIEVE STORED MESSAGE. The first such record retrieves the first 
stored message, and subsequent records retrieve the following stored 
messages in turn. It is not necessary explicitly to re-store a message 
having retrieved it, but no error occurs if this is done 


8.3 STORE CURRENT MESSAGE. This record type is only valid immediately 
following a RETRIEVE MESSAGE (NEW or STORED) , and results in the current 
message being stored. 


8.4 DELETE CURRENT MESSAGE. This record type is only valid immediately 
following a RETRIEVE MESSAGE (NEW or STORED), and results in the current 
message being deleted. 


RUNTRAILER/LOGOFF RECORD This record terminates the run. 


9.1 MAGTAPE UPDATE. The Run Trailer record contains a count of the 
number of batches expected. A summary report is printed and the run 
terminates. 


9.2 ONLINE UPDATE After receipt of this record, a 'logoff reply! (see 
App C) is transmitted and the telephone connection broken. 


SECTION 3 MAGNETIC TAPE UPDATING 


1 This section describes the requirements of the magnetic tape batch updating 


system. Detailed record layouts are given at Appendix B, with explanatory 
notes at Appendix A, and a list of error messages which may appear on the 
output report is at Appendix D. 
MAGNETIC TAPE FORMAT 
2 CHARACTERISTICS The tape used must have the following characteristics: 
2:1 NRZI mode; 
2.2 Nine track; 
2.3 800 bpi; 
2.4 No coupling; 
2.5 Reel size between 6 in (200 ft) and 10.5 in (2400 ft). 


3 TAPE LAYOUT: Data is arranged on the tape in the following layout: 
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3.1 IP LABELS (optional). These are included for compatibility with 
other computer systems, but have no significance for Prestel. All data 
before the first tapemark is ignored. 


3.2 TAPEMARK (1). Signals the start of the user data. 


3.3 ТАРЕМАВК (2). Signals the end of the user data. No attempt is made 
to read beyond the second tapemark. 


4 BLOCK LAYOUT The user data records are held in blocks in the following 
format (IBM RECFM=VB): 


T SSS 


Block header | record | record record 


4.1 The block header consists of 


2 bytes - block length (including block header) 
2 bytes - block number 


Both fields are held as binary numbers. If a block is read out of sequence, 
the run is halted. If the blocknumber field contains zero or spaces, 
block number checking is not performed. 


4.2 The maximum size of a block is 3000 bytes. A record may not be 
split between two blocks. 


5 BATCH CONTROL Data records must be grouped into batches of not more 

than 100 records, by use of batch headers and trailers (DTs 03, 04). Any 
records over the maximum are ignored. A separate count is kept of DT31 (print 
frame) records; only 30 such records are allowed in a batch. Any records 

not preceded by a valid batch header are ignored, and if the first record 
following the run header is not a batch header, the run is terminated. 


At the end of a batch, counts of each record type are compared with the 'expected' 
figures from the batch trailer. If they do not watch, a warning message is 
printed, but the run continues. 


OUTPUT REPORTS 


6 A printed report is produced listing all batch headers and trailers and 
identifying any erroneous data records. The IP's name and address from the 

run header record is printed on the first page of the report. A summary is 
printed at the end of the report identifying the number of records read, number 
of errors found, and the net change in the number of frames on the IP's database. 


7. Іп addition to the printed reports, a series of message frames is generated 
and sent to the IP, containing all the information from the printed report 
except the name and address and ‘retrieved frame' prints. The system will 

not attempt to generate more than 20 such message frames in a single run. 


SECTION 4 ONLINE UPDATING - ASYNCHRONOUS PROTOCOL 


1 This section describes the requirements of the asynchronous protocol 
used for online bulk update. Detailed input and output record layouts are 
given at Appendices B and C, with explanatory notes at Appendix A. Reply 
codes are listed at Appendix D. Telecom requirements are set out in Appendix Е 


ASYNCHRONOUS COMMUNICATIONS PROTOCOL 


2 TRANSMISSION CHARACTERISTICS. The basic transmission characteristics 
are as follows? 


2.1 300 baud (Datel 200) 
or 1200 baud (Datel 600); 


2.2 Half-duplex mode; 
2.3 1 start bit, 1 stop bit; 
2.4 Even parity; 


3 CALL SET-UP. The facility is accessed via the switched telephone network, 
by calling the appropriate bulk update number, depending on the speed required. 
The call is answered automatically, and a carrier tone is heard. The tone 
remains for 10 seconds, during which time the IP should establish the connection 
to his computer. At the end of the 10 seconds a '1' block is transmitted 

by the Prestel system, which is then ready to receive the first record 

(ie the ‘logon request'). If the logon request is transmitted by the IP before 
the end of the 10 seconds, no harm is done, as the "1" block will be recognised 
by the IP's computer as a negative acknowledgement (see 5.1 below), and the 
logon request will be automatically retransmitted. 


4 CALL PROGRESS. Having established the call, the dialogue proceeds with 
the computers sending alternate messages as follows: 


UPDATE RECORD 
RETRIEVE REQUEST | 


ERROR/ SUCCESS CODE 
RETRIEVED FRAME/MESSAGE 


| 

{LOGOFF 

|REQUEST | 
екс _____ ME ee 


5 BLOCK FORMAT To minimise the effect of transmission errors a record 
is split into blocks of a smaller size which are transmitted separately and 
re-assembled at the receiving end. The maximum size of a transmitted block 
is 80 bytes. The format is as follows:- 


PAD SOH TAG STX «data» «term ><Әсс> US 


where PAD is any non-significant character; present for timing purposes only, 
ignored by the receiving machine 


SOH 'identifies the position of the TAG character 


TAG is used for diagnostic purposes. It takes the value '0', '1', 
--- '7', '0' — etc on successive blocks transmitted. If а 
block is retransmitted because of a timeout, TAG is not 
incremented. This enables the receiving computer to detect 
missing or repeated blocks. 


Note: in the current Prestel version, the SOH and TAG characters are 
generated on all output blocks but not checked for on input. 


STX identifies the start of the data. 


< data» is the information part of the block; 
maximum length 75, minimum length O 


4term» is the data terminating character; 


ETX if this is the last block of a record; 
ETB if more blocks for the same record follow; 


<bec> is the block check character, formed by performing an 'exclusive 
or' operation on all the characters following STX (horizontal 
parity check). The parity bit itself is not included in the 
horizontal check, but is set so as to make the bcc itself have 
even parity. 


05 is the unit separator character required as a block terminator 
by the software. If the bcc character happens to be a 'US', 
the final 'US' must be omitted - ie only one US is allowed in 
any one block. 


5.1 Receipt of a block is acknowledged by a block of the same general format 
whose «data» field is a single character as follows: 


0 means the block was received correctly (but see 5.2 below); 


1 means that a parity or bcc error was detected - the block must 
be retransmitted; after 12 such retransmissions, the call is abandoned. 


3 means that the actual length of the record is not as specified 
in the 'record length' field, or that the record is too long 
for the input buffer (can be the result of transmission errors). 
The whole record should be retransmitted. If a '3' is received 
in response to an ETB block, the record must be terminated 
before it is retransmitted, by sending an ETX block, which will be 
acknowledged by a '3'. If this is not done, Prestel is unable to 
distinguish the retransmitted record from the previous one, and will 
therefore give a '3' reply to the retransmission as well when the 
ETX is eventually received. 


6 


5.2 Positive acknowledgement of the final block of a record (ie one 

terminated by ETX) is neither required nor expected; it is in fact implied by th 
transmission of the next record, which will normally be an update success 

or failure code from the Prestel computer, or another data record from the 

ТР. If an acknowledgement ('0') block is sent under these circumstances, 

it is treated by Prestel as if it were a new data record, and failed 

with code 3 (record length error). 


TIMEOUTS To guard against the possibility of a block being lost in transmissior 


a timeout is applied after each block is sent. If no return message is received 
within the timeout period, the block is retransmitted. If no reply is received 
after 12 such retransmissions, the call is abandoned. The timeout values currently 
applied are (approximately): 


6.1 after transmission of ETB block: 2 seconds 


6.2 after transmission of ETX block: 10 seconds 


To avoid the possibility of both computers timing out and retransmitting at 
the same time, the IP should employ different values - say 4 and 12 seconds. 
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ERROR CONDITIONS 


7.1 Under conditions of heavy load, it is occasionally possible for 

a retransmission to occur when no transmission loss has actually occurred; 
this can result in a block being received twice. In such a case, the 
"record length' check which is applied after receipt of the ETX block 
will detect the error and result in the whole record being sent again. 


A similar record length check should be applied by the IP on receipt 
of a retrieved frame or message (DTs 03, 04, 05). If the check fails, 
retransmission must be requested by sending again the original request 
(DT 31, 41, 42) rather than by sending simply a '3'. 


7.2 In some circumstances it is possible for the IP to treat Prestel's 
retransmission of a block as if it were the reply to a new request from 
the IP. This is particularly unfortunate if the records involved are 

a 'retrieve frame' request from the IP and a 'page/frame does not exist' 
from Prestel. The use of the TAG character (see para 5) should assist 
in detecting this situation; alternatively, it may be found prudent for 
the IP's computer to retry automatically every failed 'retrieve frame' 
request. 


7.3 If an invalid block is received in reply to an ETB block (when 

'Q', '1' or '3' is expected) it should be ignored: if it was pure noise, 
the 'real' block will arrive soon, if it was the 'real' one, but corrupted, 
the timeout mechanism will arrange for retransmission. 


If the block received in the same situation is not invalid but unexpected 
(ie not a "0", '1' or '3'), it should be treated аз а "0": any other 
reply is likely to involve further retransmissions followed by loss of 
the call. 
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PRESTEL BULK UPDATE 
NOTES TO RECORD FORMATS 
1 This Appendix explains the various codes and symbols used in the record 


layouts in Appendices B and C, and also describes the contents of the various 
fields. 


Some record types are applicable to both online and magtape update - these are 
headed 'BULK UPDATE' - whereas others are headed 'МАСТАРЕ UPDATE' or 

"ONLINE UPDATE' as appropriate. 

COLUMN HEADINGS 

2 POSITION. These columns define the position of the field in the record. 
3 FIELD-NAME. ‘Describes the contents of the field. 


4 PICTURE. Describes the format of the data within the field. The codes 
used have the following meanings: 


ZN = numeric characters, right-aligned, zero-filled. An unused entry 
(eg in the CUGS field) consists of all zeroes or all spaces. 


SN - numeric characters, right-aligned, space filled. An unused entry 
(eg an 'invalid choice' entry in CHOICES) consists of all spaces. 


А = Upper or lower case alphabetic character (not space) 
AN = Upper or lower case alphabetic, or numeric character. 


У = any viewdata character except cursor controls (ie columns 0 & i 
of the code table) but including ESC, CR, LF. The FF (clearscreen) 
character is also allowed, but only for the specification of response 
frames (see 11.5 below). In addition the characters SI, SO, SS2, 
SS3 are acceptable; they are reserved for use with specialised 
terminals in the specification of alternate character sets. 


5 SIZE. Shows the size of the field in bytes. 
6 OCCS. Shows the number of times the field is repeated. 
FIELD CONTENTS 


7 RECORD LENGTH. All record lengths are inclusive of the record length 
field itself. For magtape records, the field consists of two subfields: 

the first two bytes hold the length in binary, the second two bytes are ignored. 
For on-line records, the format is ZN - a four digit decimal number. 


8 CUGS 


8.1 USER ACCESS. This corresponds to the ‘user access' prompt in the 
online editor. A value of Y or space signifies that all users (subject 
to CUG check) may view the frame, while a value of N means that only 
the IP himself may access it (regardless of CUG checks). 
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8.2 CUG. Any frame may be placed in any CUG which the IP owns, by quoting 
the appropriate 5-digit CUG number. If the field is all spaces or all 
zeros, the frame is placed in CUG number 2 (the 'null CUG'), to which 
all users have access. This value will also appear in a 'retrieved frame'. 


9 CHOICES. The ten choice fields denote the page numbers to be selected 
when the user keys the digits 0-9 respectively. If any choice field is left 
blank, the choice is invalid, and the user will receive the 'SORRY NO SUCH 
PAGE! response. 


10 FRAMETYPE. Upper or lower case alphabetic; I, i or space denotes an 
information frame, A, a, R or r denotes a response frame. 


11 FRAME CONTENTS 
11.1 A line of data displayed on а viewdata screen consists either of: 
ae exactly 40 displayed characters; or 
be less than 40 characters, terminated by CR LF characters; or 
с. a blank line, consisting of CRLF, ог LF alone. 


11.2 The 'frame contents' field consists of up to 23 such lines. The 
first line of the input data is always replaced by the standard Prestel 
line 1 (IP logo, page number, price). The top line may be represented 
in the input record by the minimum length line CRLF, or just LF. Any 
data beyond the 23rd line is ignored, as the Prestel system uses line 
24 for system messages to the user. 


11.3 Every viewdata control character (columns 4b and 5b of the code 

table) is identified by being preceded by an ESC character. The control 
character itself occupies a single position on the screen, but the ESC 

does not, so a data line input to the bulk update system may contain 

more than 40 actual characters, provided that the number of displayed 
characters (ie excluding ESC) does not exceed 40. However, the total 

space available within the system for storing a frame including ESCs, 

is 920 characters for an information frame or 716 characters for a response 
frame. Line 1 occupies at least 43 characters (depending on the number 

of control characters in the IP's logo), so the space available for an 


IP's data is 877 characters at most. To make the most of the space available, 


the Prestel system 'optimises' the frame contents by removing spaces 
at the end of lines, replacing them by CRLF characters. If the frame is 
still too long after this optimisation, any excess characters are ignored. 


11.4 The only cursor control characters which may appear in the 'frame 
contents' field are CR LF. If any other cursor controls are present, 
or any other invalid characters, they are replaced by DEL characters, 
which appear on the screen as a white box. If this occurs more than 
20 times on a single frame, the record is rejected (code V, see App D2). 


11.5 RESPONSE FRAME A dialogue field is signalled by a 'clearscreen' 
character (НЕХ!0С!) followed by a permissible dialogue character (lower 

case a-z). This is then followed by any number of the same dialogue 
character; the end of the field is signalled by the first occurrence 

of any other character. The 'clearscreen' character becomes the 'privileged 
space' and the dialogue characters define the dialogue field. The standard 
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dialogue characters eg 'n' (name), 't' (telephone number) 'd' (date and 
time), 'a' (address) have the sane special significance as for the online 
editor, and free format fields (to receive user data) are denoted by 

any other permissible dialogue character - conventionally 'f'. 
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Record пате маСТАРЕ UPDATE — RUN HEADER 


Max length 


165 bytes 


= Те Ме —] 
Ето! 

с=с 

Свен |4) 


35 | ТР МАМЕ 


Lis GET TTE TENE 


56 175 Ы LINE 2 у 


]window envelope 
)to return update 
)report to the 
linformation provider 


SYSTELNO 


EDIT PASSWORD 


printed at the head 
of ihe listing; 

can be used by the I 
to identify the revo 


Мош WAGTAPE UPDATE ONLY 


See Appendix A for notes 
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Record name — viorAPE UFDATE — RUN TRAILER 


Max length 10 bytes 


Position 
From| To |Field-name 


mmo imum: |_| see sosed | a] | 
ЖЕСІ Lom || | 


BATCH COUNT 


MAGTAPE UPDATE ONLY 


See App A for notes 
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Record пате oxp туш UPDATE — LOGON REQUEST 


Max length 20 bytes 


Position 
B CI Пе ымы | 
| [[›[шотшвын___ [еже | | Тео | 
ар ею || ж || |-о» _____ 
| [eff || ш | 
Pts | | веште | | 


n 19 | EDIT PASSWORD 


ONLINE UPDATE ONLY 
REPLY WANTED determines the type of reply wanted if logon is successful: 


О за simple '0' reply code is sent 
15: & full message (as in App C Sheet 1 
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Record пате бут туг: UPDATE — LOGOFF REQUEST 


Мах length 6 элеш 


Position 
From| To |Fieid-name Picture 
mnn | = || 
ао | кою те Па || к сазана! 


ONLINE UPDATE ONLY 
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Record ТАРЕ UPDATE — BATCH HEADER 


Max length 10 bytes 


| ите || къз ПРА о | 

Ғтот| To |Fieid-name 

о |з Тешово Й РАНА | „| [ar | 

Та temo ers [S a js] |. | 

| jele]memem ||] om | „| | 0 0 | 
НЕТ | | 


МАСТАРЕ UPDATE ONLY 


See App A for notes 
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Record name | МАСТАРЕ UPDATE — PATCH TRAILER в | 


Мах length 3| bytes 


Pesition 
Егот| То |Fieid-name на La 
ED 3 RECORD LENGTH See notes | | 
nnr-r- а | 


2 = Мо of РТ12 


of РТ21 


EE ME 
ЕНЕ НС И не 


þm 
6 = 


MAGTAPE UPDATE ONLY 


See App A for notes 
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Record name вух UPDATE - REPLACE FRAMETABLE | 8 


Max length 1080 bytes 


| мө Р | вы ова | 
Ғгот| То Picture 
__ о | века мали | see | | | 0 y 
|| Кое ||“ || 
| [efs fence women || || || 
| [s| [prae seme ||, ОИ are 
а ај 
ама иа | 
af Пий 
FRAMEPRICE pence, max 50p 
| 
кишин 
| | mese: | 
INNEN ККЕ 


See App A for notes 


2 1f the FRAME CONTENTS is not present (RECORDLENGTH - 127 or 128), only the 
frame table information is amended. If only a single byte is present after the 
FRAMETYPE field, this is not deemed to constitute a frame. 

If the RECORDLENGTH is 129 or 130, the frame contents are cleared to spaces. 
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Record пате ди UPDATE — DELETE PAGE 


Мах length 15 bytes 


Position 
Ғгот| То |Fieid-name 
oe PEDOED LENGTH 


RECORD TYPE 


PAGE NUMBER 


See App A for notes 
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DIM CIR 


Max length 1080 bytes 


Leon ts ССЭ 
From| To | Field-name Picture 

| [o| a [recono mnom | ee notes || 
јот | 
еа [pace wms | 
|| 15 FRAME ‘IDENTITY 

| Геј fusee access ||, || 
| (еј Ја || 


N=no, Y or space=yes 
00000-32767 


Price in tenths of 
pence, max 50D 


See App A for notes 
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Record name BULK UPDATE - REPLACE FRAME 


Max length 976 bytes 


ition 
EE Р ааа 
IEEE TT 


Upper or lower case 
phahetic 


See App A for notes 


Record name BULK UPDATE — DELETE FRAME 


Max length 16 bytes 
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Position 
From| То Occs |Notes 


222. 


= 16 


Upper ог lower case 


INDICI: кише НН НН 


To delete frame tat, record type 12 must be used 


сілкскезіде wot tir 
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Record name 
BULK UPDATE - RE-INSERT FRAME 


Max length 1080 bytes 


Ешім ЕР 

From| To |Fieid-name лае. - 
Eis ОН Р ЕНН 
| | 5 | RECORD ТУРЕ 

[| efre [ence women | 
Са мент | 


CUG 


[afso ПЛ 
ШЕ FRAMEPRICE ` | 


See App A for notes 


This record will replace an existing frame, or act as an ‘insert’ if the frame does 
not exist. 


Record name 


BULK UPDATE-RETRIEVE FRAME 


Мах length 16 bytes 


СЕ 


Зее по+еѕ 


Lom [| 


See App A for notes 
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Record name 


ONLINE UPDATE-RETRTEVE NEW MESSAGE 


= 100061 


Position 
From| То |Fieid-nams iun Notes 


ONLINE UPDATE ONLY 
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ONLINE UPDATE ONLY 
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Record name — QNLINE UPDATE - DELETE MESSAGE 


Max length 6 bytes 


Position 
Егот| To Size Notes 
--- meom LENGTH Пе Пее | 


ONLINE UPDATE ONLY 


1 This record must be immediately preceded by either RETRIEVE NEW MESSAGE 
or RETRIEVE STORED MESSAGE and will apply to the mesaage just received. 
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Record пате | ONLINE UPDATE — STORE MESSAGE 


Max length 6 bytes 


Position 
From To 
Сее а П = 


Notes ONLINE UPDATE ONLY 


1 This record musi be immediately preceded by either RETRIEVE NEW MESSAGE 
RETRIEVE STORED MESSAGE and will apply to the message just received. 
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Record name ONLINE UPDATE — LOGON OK REPLY 


аи 
Ғгот| To 
| - о» O 

ER ЕТТІ ТӨНЕ = 
ШЕ рење Me ИГИ ИИ БИИ 
E pelos Ml es | |m 
ШЕГІР: р o mss 

>} ют а «ү 
-| ә 4 | 


й 
- са 


This message is sent іп reply to а logon request record with REPLY WANTED set to 1. 
The IPLOGO is іп a similar format to the 'frame contents! held on other records 


а every control character is preceded by ESC 
b Aline is either 24 non-ESC characters or fewer characters terminated 
by CRLF 

c  LOGOLENGTH includes ESC and CRLF characters 
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Record пате сут тур UPDATE - LOGOFF REPLY 


Ген omn ами TR 
eee И 
Е РИ 
Егот| То 
јет ЕІГІНЕРЕ ЕШ ПЕ | 
јато |“ | 
IIR T РН 


еи 1 Е: ГА НН 
Cr а Пеј 


1 If FRAMES USED is greater than FRAMES ALLOCATED, the system manager is 
informed. 
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везе тат ачык UPDATE - RETRIEVED тона 


Max length 1120 bytes 


Position 
a. Tele 
ae 1 |REPLY TYPE [жї | fa | | - о“ ______| 
ДЕНЕ с eec 
Пън ||. Ды, 


ШЕН АССЕ55 


SEEC 
Tat [жени 


mum umm 
16 Е 
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Record name ONLINE UPDATE - RETRIEVED MESSAGE 8 


Max length 948 bytes 


мышы | йет 

СЕО нина DUM I НЕ ARR 

ШЕНІ: З ОН —3 

= жє T И ЕЛ О И 

э ы уз» - 
ME 


920 


- Max length 920 


See Response Frame Facility, IP Manual 


2 REPLY ТҮРЕ "ОД" - new message 
'05' - stored message 


3 DATE AND TIME are of sending (new message) or storing (stored message) 
NOT of retrieving 


APPENDIX D - UPDATE MESSAGES 

ANNEX 1 LOGON FAILURES 
2 UPDATE FAILURES 
3 BATCH CONTROL REPORTS (MAGTAPE ONLY) 
4 MESSAGE CONTROL FAILURES (ONLINE ONLY) 


5 TRANSMISSION REPLIES (ONLINE ONLY) 


Note: for MAGTAPE, the whole message is printed 


for ONLINE, the single character code is transmitted. 
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ANNEX 1 - LOGON FAILURES 


CODE MESSAGE NOTES 
е------ оно  -- ee 


А RUN HEADER MISSING Run header/Logon request 
record missing 


B UNKNOWN USER Systelno in Runheader/Logon request 
record invalid 


с INVALID PASSWORD Password in Runheader/Logon request 
record does not match entry in userfile 


8 SYSTEM FULL The maximum number of Bulk Updaters 
are already logged on 


| 9 SYSTEM CLOSED 


нн нн 


NOTES 
1 MAGTAPE; after any of these messages the run is halted. 


2 ONLINE; after any of these messages the line is cleared and a new call 
awaited. 
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ANNEX 


CODE 


mi Q "db oc 


чо 


аю 


dv x 


NOTES 


1 
do no 


IX D 


2 - UPDATE FAILURES 


MESSAGE 


INVALID RECORD TYPE 


PAGE ALREADY EXISTS 
PARENT DOES NOT EXIST 
| PAGE DOES NOT EXIST 
| FRAME ALREADY EXISTS 
| 
| 


DISC ERROR 
NOT LAST FRAME 


FRAME DOES NOT EXIST 
PRIVATE CUG 

NOT END PAGE 

FRAME ALLOCATION ÉXCEEDED 
INVALID PAGE NUMBER 
INVALID FRAME IDENTITY 
UNAUTHORISED ACCESS 


MASTER PAGE 
INVALID FRAME TYPE 


INVALID CUG 

INVALID CHOICE TABLE 
INVALID FRAME 
INVALID PRICE 


TOO MANY DIALOGUE FIELDS 
INVALID DIALOGUE CHARACTER 


NOTES 


Attempt to insert existing page 
Attempt to insert 'orphan' 
Attempt to update non existent page 


System failure - inform Prestel Operations | 


Attempt to delete a frame which is 


not the last of a page, or insert one 


whose predecessor does not exist. 


Frame is in a private CUG and cannot be 


accessed 


via a dedicated circuit 


(International service only). 
Attempt to delete a page which has 


filial(s) 


Frames in use exceeds frames allocated 


(for this IP). Further attempts to insert | 


new frames are rejected. 


Includes attempt to use dt 23 to delete 


frame 'а' 


Attempt to access a page not owned by 


this IP 


Attempt to delete a master page 


Includes 
frame by 
Includes 
owned by 
field 

Contains 


attempt to set up response 
an IP who is not allowed to 
attempt to quote a CUG not 


this IP, or invalid 'USER ACCESS' 


non-numeric characters 


Frame contains too many invalid 
characters 


> 50р (999p for international system) 


224 fields on a reponse frame 


First character after 'clear screen’ is 


not in range a-z 


These are output in response to invalid updates to the Framefile but 


t cause the run to halt. 
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ANNEX 3 - BATCH CONTROL REPORTS (MAGTAPE ONLY) 


1—4 


МЕЅЅАСЕ NOTES 


ABANDONED — NO BATCH HEADER The first record after the run header 


| 
is not batch header. The гип is halted.| 


BATCH HEADER MISSING А data record has been read 
- FOLLOWING RECORDS IGNORED without a preceding batch header. 


TOO MANY RECORDS IN BATCH | | 
- EXCESS IGNORED 


BATCH TRAILER MISSING A batch header or run trailer record 
has been read without a preceding 

batch trailer. 

BATCH попа RECONCILIATION ОК Where nnnn represents the batch number. 


BATCH пппп RECONCILIATION FAILED This is followed by a report of the 
figures expected and found. | 


RUN TRAILER MISSING 
BATCH COUNT OK і 


BATCH COUNT FAIL This is followed by a report of the 


| number of batches expected and found. 


NOTES 


Т, These reports only apply to magtape batch update. Except where stated 
batch control failures result in a warning message only, and do not halt the run. 
2 A number of statistics are printed at the end of a run, whether. the 


reconciliation is successful or not. These consist of: 


IP's frame allocation and usage; 
Number of record processed and number rejected; 
Net change in the number of database frames used by the IP. 
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ANNEX 4 - MESSAGE CONTROL FAILURE (ONLINE ONLY) 


No more messages to retrieve 


the message due to a system 


| 
(Hex '5В') can't save/delete/send | 
| 
| failure | 
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ANNEX 5 - TRANSMISSION REPLIES (ONLINE ASYNCHRONOUS PROTOCOL) 


| 
CODE | 


m 


MEANING 


Block/message received and processed correctly. 


i After ETB block: block received correctly; next block 
expected 


ii After ETX block: record received correctly and update | 
applied, next record expected. 


Note that '0' is also the first character of the successful 
logon and logoff replies, and of the 'retrieved frame' reply. 


Block parity error(s) or block check fail: retransmitted 
block expected. If more than 4 such errors occur in succession, 
the run is abandoned. 


Record length error (ie different from 'record length' field 
or too big for input buffer); record is ignored. 


SYSTEM FULL 


SYSTEM CLOSED 


NS Nd —— ннен 


Codes 0-1 are also used by the IP's computer in acknowledging blocks of a 
long record sent by Prestel (eg a 'retrieved frame'). 


APPENDIX E 
EDITING TERMINALS - TELECOM REQUIREMENTS 


The following sets out the requirements for such terminals to be acceptable 
for connection to the telephone network. 


1 The function of receiving Prestel shall be in accordance with the latest 
issue of the Viewdata Service Terminal Specification. 


2 Communication with the bulk update function of the computer shall be 

made via a British Telecom Datel Modem. For 1200/1200 working a Datel 600 installati 
to British Telecom Service Code 604/R/111 is likely to be suitable. Details of 
the modem are to be found in Technical Guide No 5(2). Protection requirements 
for the modem interface are to be found in Technical Guide No 26(2). 

3 Permission to attach the terminal equipment to BT lines is given by 
British Telecom, Residential and Customer Services Department in accordance 
with Technical Guide 26, before the equipment is offered for sale or hire. 
Provisional permission should also be sought before development is started. 
Initial approaches with a view to connection to Prestel should be made to 
Prestel UK Marketing Division (Prestel 4.1.2). 


4 Data exchanges with the bulk update system shall be in accordance with 
the communication protocol given in Section 4. 


5 Technical enquiries concerning this specification should be referred 
to: 


Prestel 4.3.2 
Telephone House 
Temple Avenue 
LONDON 

ECAY OHL 


Telephone: 01-583 9811 
6 References:- 


L Viewdata Service Terminal Spec. Obtainable from Prestel 4.1.2 (see 
para 5 above). 


2 Technical Guide No 5 and No 26 obtainable from: 


British Telecom Marketing Executive 
8С$1.2.1.4 

Tenter House 

45 Moorfields 

LONDON 

EC2Y 9TH 


4 ханааду` 


53000 NOISSIWSNVYL угуамчл, 


E Зе азеајан | ЕН о sn Is tha 
әшо| 
Ең 59140109 дон | м su оста 05 ез 
РД риполбуоев мам |+ збен лоб | и ess НЭ зот отъ 
зва 

EH риполізрев раја | и WBPH ешюм | 1 258 | „иа 011 

m 1л 
Ў == ирд ueis | Я 053 { зо tor 

sorydesey al 
ў У paredes | 2 ирз pug | г ans р 19:00 tot 

1H 
ЁЗ S914989 Snuog | д Apeag | | из =— юзпо 001 

58 
FH А1010 jeasuog | x weld |н м5 == кио oot 
а! BUUM боцаело |М ЗИЧМ eudiy | є 901$ одеј ЕТЕ] 18 БЕО 
U^) дее | A ЧО eydy 4 11215 одеј NAS мом гъо 

еде 
BWEN әніне | гү шәбе ца | з uo asneg ade]. ум ома ото 
ШЕКТІ) ang eydy әроуу әшшелбоз{ 3: 
еее | 1 ччам | а d 125 aries Loa 010 
ОПА свело | 5 MOURA eudiy | 2 (E) нед 125 коа xia 100 
9999 ssudeso | y 49929 eydiy | g (2) AmA 55 га х1$ 100 
РӘН sorydesg [О РӘН ецагу | м | (порой Aman 195 чо HOS 000 
128 osang 
d à зла INN 0000 
as 5 ар v чє 0 144547454944 | sn | 
1 0 
0 0 П 0 


